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FOREWORD 


This report documents The Aerospace Corporation effort on 
Study 2.3, Systems Cost/Performance Analysis, performed under NASA 
Contracts NASW-2575 and 2727 during Fiscal Years 1974 and 1975. The 
effort was directed by Mr, B. H. Campbell. Mr. R. D. Kramer, Ma.rshall 
Space Flight Center and Mr. R. R. Carley, NASA Headquarters were 
the NASA Study Directors for this study. Their efforts in providing tech- 
nical direction throughout the duration of the study are greatly appreciated. 

This volume is one of three volumes of the final report for 
Study 2.3. The three volumes are: 


Volume I 
Volume II 
Appendix 
Volume III 


Executive Summary 

Systems Cost/Performance Model 

Data Base 

Programmer's Manual and User's Guide 


Volume I summarizes the overall report. It includes the 
relationship of this study to other NASA efforts, significant results, study 
limitations, and suggested additional effort. 

Volume II provides a detailed description of the Systems Cost/ 
Performance Model. It also includes the model checkout and the results 
for three payload test cases. The Data Base is provided in the Appendix 
to Volume II. 

Volume III provides a detailed description of how the Systems 
Cost/Performance Computer Program is organized and operates. The 
program listing, detailed flow charts and user restrictions are included. 
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1. INTRODUCTION 


As the space program matures into an applications industry, 
greater emphasis will be placed on improving the ability to predict the 
effect of program requirements on cost and schedxiles. Cost estimating 
techniques that give greater insight earlier in the program cycle are re- 
quired. As a step in this direction, this study was initiated to identify and 
quantify the interrelationships between and within the performance, safety, 
cost, and schedule parameters for unmanned, automated payload programs. 
These data would then be used in support of the over-all NASA effort to 
generate program models and methodology which would provide the needed 
insight into the effect of changes in specific functional requirements (per- 
formance and safety) on the total vehicle program (cost and schedule). 

Previous cost modeling approaches fall into one of two basic 
categories: "bottom-up" or "top-down". The "bottom-up" approach, which 

is tied to the development of a specific system, depends on detailed esti- 
mates of tasks, material costs, manpower requirements, and schedules. 

The total cost estimate is then obtained by summing the individual costs. 

"Top-down" models use CER (cost estimating relationship) 
approaches to estimate the cost of a specific system. In these models, the 
CERs are related to distinct parameters such as weight, (see Figure 1-1). 
The deficiency of the CERs lies in the fact that, although they identify 
cost drivers, they do not model why and how the costs are driven by the 
parameters. 

Since CERs have not been completely successful in meeting the 
prime criterion of determining sensitivity of cost to changes in program 
requirements, top-down approaches were judged unacceptable for a cost/ 
performance model. Hence> it was thought that a model oriented from the 
bottom-up could lead to fulfillment of this criterion. The bottom up approach 
would allow the cost estimates to be based directly on technical performance 
(see Figure 1-1) and design complexity. 


CURRENT CERs SYSTEMS COST/ PERFORMANCE MODEL 
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2. OBJECTIVES 


Study 2.3 had four objectives. The first objective was to 
refine and improve the cost/performance methodology which was developed 
during the preceding fiscal year's study {see Ref. 2-1). The same two- 
step process of first establishing hardware designs and then estimating costs 
and schedules was retained. However, incomplete portions of the meth- 
odology such as the cost and schedule models were to be improved. 

The second objective was the application of the cost /perform- 
ance methodology to the following vehicle subsystems; 

a. Stabilization and Control (S&cC) 

b. Auxiliary Propulsion Subsystem (APS) 

c. Communications, Data Processing and Instrumentation (CDPI) 

d. Electrical Power Subsystem (EPS) 

1. Sources 

2, Conditioning and distribution 

e. Thermal Control Subsystem (TCS) 

f. Structure 

The product of this effort is the Systems Cost/ Performance Model. 

The third objective was to implement the Systems Cost/ 
Performance Model as a digital computer program. 

The fourth objective was to bring the Systems Cost/Perform- 
ance Computer Program to an operational state on the MSFC Univac 1108 
computer. The resulting program would be used by MSFC to perform 
initial program planning, cost /performance tradeoffs, and sensitivity 
analyses for mission model and advanced payload studies. 


3. RELATIONSHIP TO OTHER NASA EFFORTS 


The FY 1974 Study 2. 3 made extensive use of the FY 1973 
Study 2,3, System Cost/Perfoi‘mance Analysis , results. The cost/ 
performance methodology developed during the preceding year's effort 
was improved and refined. This improved methodology was used to 
develop a model applicable to unmanned, automated payload subsystems. 
The FY 1975 Study 2. 3 was a continuation of the FY 1974 
study (Ref. 3-1). The input portion of the Model was reorganized. The 
current cost model was incorporated into the computer program. The 
program printout was enlarged and improved. Three test cases and six 
trade studies were performed using the computer program. 

The System Cost/Performance Model's data base formula- 
tion v/as based on the REDSTAR data base currently in use at MSFC. The 
REDSTAR system is the result of a 1972 fiscal year study (Ref. 3-2). 
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4. APPROAOW 


One of the first tasks in this study was to define the spacecraft 
generically by determining the functions performed by each spacecraft sub- 
system and the functions performed by specific hardware types within each 
subsystem. Obviously, interfaces between subsystems determined some 
of the functions to be performed. The outline of functions to be performed 
had to be complete in that potential subsystem designs, for the most part, 
are related directly to the functions they are required to perform. 

Block diagrams were developed for all generally used subsystem 
configurations. The block diagrams consisted of the equipment types used 
in each configuration and illustrated the functions performed by the equip- 
ment. Since there may be an infinite number of block diagram variations, 
certain general block diagrams were established that were valid for most 
designs. 

A design algorithm was developed which performed the function 
of selecting preconfigured subsystem designs satisfying the input system 
or subsystem requirements. This implies that, as part of the vehicle 
design algorithm, a complete set of alternative designs has been established 
from which to choose. 

Given a specific design meeting the input requirements, the 
hardware required to implement such a design is selected from 
available off-the-shelf hardware which is contained in the data base. 
Obviously, the model must be capable of differentiating between hardware 
components of the same type and determining which hardware component 
has the characteristics to satisfy all of the requirements. 

In order to have a workable algorithm, the list of input data 
necessary to select a design and to size the necessary equipment has been 
established. The input data would normally include subsystem perform- 
ance requirements, interface requirements, and any other data necessary 
to make design decisions. The input data list is extensive in order to 
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allow specialists to crserclse a great deal of control over the model. On 
the other hand, representative values were established which the model 
used in the event that the user did not wish or could not specify all of 
the input data. 

A data base consisting of information on off-the-shelf hardware 
was established. The data content which is associated with each hardware 
component consists of four categories of information: 

a. Performance 

b. Safety (Reliability) 

c. Cost 

d. Schedule 

The four types of data contain sufficient information to allow t**e equipment 
selection algorithm to select specific pieces of equipment and to provide 
the necessary output data describing the design. The data were collected 
from in-house, Air Force, and NASA sources. Cost data were based on 
.seven specific satellite programs. 

The Systems Cost/ Performance Model was implemented as a 
digital computer program. The program was written in the language of 
Fortran IV for the Aerospace CDC 7600 computer and adapted for the 
MSFC Univac 1108 computer. The program includes the Systems Cost/ 
Performance Model and the related data base. 

The computer program printout was to include three levels 
of detail, any of which could be requested by the user. The three levels 
of printout corresponded to the system, subsystem, and assembly level 
of design. The appropriate design, cost, and schedule information would 
be printed out at each of these levels as requested. 

Two forms of model checkout were performed. The first was 
a set of computer rims to ensure that both the logic and arithmetic models 
were accurate and complete and that all submodels were interfacing 
properly. The second se'^ of computer runs was limited to a few special 
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runs, selected for the purpose of comparing the Systems Cost/Pt rform- 
ancG Model against other existing models and against actual payload 
programs . 

Support was provided by The Aerospace Corporation to 
MSFC to bring the Systems Cost/Perfoimance Computer Program to an 
operational state on the Uni vac 1108 computer. This support consisted 
of both engineering and programming support. The computer program 
and data base wore altered as required in order to be compatible with 
the Uni vac 1108. 



5. SYSTEMS COST/PERFORMANCE MODEL 


5. 1 GENERAL 

The general concept of the Systems Cost /Performance Model is 
illustrated in Figure 5-i. The user of the Cost /Performance Model must 
supply certain program data which would normally include the payload per- 
formance requirements as well as general information necessary to select 
a payload design. The technical portion of the model consists of a two-step 
process; the first step is to select subsystem configurations which are 
acceptable to the user, and the second step is to select equipment from a 
dara base to mechanize the subsystem coni’iguration. The reliability portion 
of the model adds redundancy to the design so that the reliability require- 
ments are met. The resulting output of the technical model is a number 
of payload designs which meet or exceed the input requirements. The 
acceptable designs are specified down to the subsystem component (assembly) 
level. The cost and schedule required to design, build, and operate* each 
payload are estimated by sui.v.ning up the individual cost and schedule allo- 
cations based on each end item assembly specified as part of the particular 
design. 

The technical portion of the Systems Cost/Performance Movdel 
is depicted in Figure 5-2. The expanded detail summarizes the inputs 
required by each subsystem. Most importantly, the interaction between 
subsystems as a design problem is illustrated. In order to design the 
stabilization and control (S&C) subsystem, the vehicle weight, dimensions, 
and moments of inertia must be known. Design of the auxiliary propulsion 
subsystem (APS) requires knowledge of the total impulse and thrust levels 
from S&C. Design of the data processing subsystem requires knowl- 
edge of the telemetry and data processing requirements for each piece 
of equipment in the vehicle. Design of the communication subsystem 
requires knowledge of the command and communication requirejtnfsnts 
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for the entire vehicle. One must know the power requirements to design 
the electrical power (EP) subsystem. Determining the structural makeup 
of the vehicle and the weight, dimensions, and inertias requires some in- 
sight into what is contained within the vehicle and what the environment is. 
The reliability requirements impact the design of every subsystem through 
the addition of redundancy. The principal point to be made here is that by 
modeling the interaction of the subsystem design processes, the Systems 
Cost/Performance Model is not only a subsystem design tool, but is also 
a system design tool. 

5.2 SUBSYSTEM MODELS 

5, 2. 1 Subsystem Configurations 

A subsystem configuration is a general design type which is 
developed mechanically by selecting appropriate equipment listed in 
the data base. The subsystem configurations (types) incorporated in the 
Systems Cost/ Performance Model are as follows: 

a. Stabilization and Control 

1. Dual spin 

2. Yaw spin 

3. Three-axic mass expulsion 

4. Mass expulsion with control moment gyros 

5. Mass expulsion with pitch momentum wheel 

b. Auxiliary Propulsion 

1. Cold gas 

2. Monopropellant 

3. Bipropellant 

c. Electrical Power Source 

1. Body-mounted solar arrays 

2. Oriented solar array paddles 
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d. Electrical Power Conditioning 

1. Shunt regulation 

Z. Shunt and discharge regulation 

3. Series load regulation 

e. C ommunications 

1. Separate uplink and downlink 

2. Unified link, common antenna 

3. Unified link, separate antennas 

4. Unified link, common antenna, plus separate downlink 

5. Unified link, separate antennas, plus separate downlink 

f. Data Processing 

1. General purpose processor 

2, Special purpose processors 

g. Thermal Control 

(Dependent upon other subsystems and component requirements) 

h. Vehicle Shapes 

1. Cylinder 

2. Box 

3. Sphere 

i. Structure 

1. Semi-monocoque 

j. Redundancy 

1, Single system 

2. Dual system 


5. 2. 2 Equipment Description 

The model selects equipment for a specific design in one of 
three ways: 

a. Most equipment is selected from the data base on the basis of 
technical performance. 
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b. Some equipment which cannot be differentiated on the basis of 
technical performance is called up from the data base on a 
first-called basis in order to provide a complete design descrip- 
tion. 

c. Certain equipment is not amenable to being cataloged in the data 
base. This equipment is identified and specific parameters are 
determined. Examples include the wiring harness and the 
thermal control subsystem components. 

An example of an equipment description in the data base is pro- 
vided in Table 5-1. 

5,2.3 Design Algorithms 


The design algorithms for all subsystems are summarized as 

follows: 

a. Stabilization and CQntrgl Subsystem 

1 . Selects attitude measurement equipment 

2. Selects momentum exchange equipment 

3. Computes attitude control thrust level 

4. Computes total impulse required 

b. Auxiliary Propulsion Subsystem 

1. Selects thruster equipment 

2. Selects propellant equipment 

3. Selects pressurant equipment 

c. Data Processing Subsystem 

1. Selects computer or one digital telemetry unit per 
communication downlink 

2. Selects command distribution equipment 

d. Communication Subsystem 

1 . Selects communication equipment 

e . Electrical Power Subsystem 

1. Sizes solar array 

2. Selects batteries and voltage regulation equipment 

3. Selects power conditioning equipment based on require- 
ments of all other selected equipment 

*It is proposed that this category be eliminated in future models by 
differentiation of all equipment as suggested in paragraph a. 
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f. 


Thermal Con.ti-ol Subsystem 

1, Sizes thermal mass, insulation, heaters, radiators, 
louvers, and heat pipes 

g. Vehicle Sizing 

1. Estimates structural weight 

2. Estimates thermal control weight 

3. Estimates mechanism, booms, and electrical harness 
weight 

4. Sums total vehicle weight 

5. Estimates payload adapter weight 

6. Estimates vehicle dimensions 

7. Estimates moments of inertia 

h. Structural Subsystem 

1. Determines actual wall thickness based on optimum 
weight design 

2. Determiines stringer size and spacing 

3. Determines frame size and spacing 

4. Sizes end covers and center plate (if applicable) 

5. Sizes mission bay and solar array extensions 

The user must specify the following inputs as the minimum input data: 

a. Mission lifetime 

b. Orbit altitude 

c. Mission equipment weights and power requirements 

Other inputs can be specified in order to exercise greater control over 
the design algorithms. 
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Table 5-1. Data Base Example 


Subsystem: Auxiliary Propulsion (0808) 


Coniigurations: Monopropellant 


Equipment Type: Thruster (TRW 404620) 


Performance 


Technical Characteristics 


(1) Thrust level (N) 

18 

(2) Pulse life (cycles) 

93, 000 

(3> Inlet pressure (N/m ) 

4. 14 X 10^ 

(4) Total impulse (N-sec) 

6, 49 X lo"^ 

(5) ISP (sec) 

230 

(6) 


(7) 


(8) 


(9) 


(10) 


Powe r 


Average Power (watts): 

(near zero) 

Maximum Power (watts): 

5. 5 

Minimum Power (watts): 

0.0 

Nominal Voltage (volts): 

28.0 

Maximum Voltage (volts): 

32.6 

Minimum Voltage (volts): 

26.0 

Converter /Inverter Requirement (flag): 

N. A. 

Weight (Kg); 

0.3 

Volume (cc); 

1700 

Vibration 


Randon (g, rms); 

19.5 

Non- Random (g); 

10.5 

Tempe rature 


Maximum (deg K); 

322 

Minimum (deg K): 

278 

Pressure (N/m^) 

(Unknown) 
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Table 5-1. Data Base Example (Continued) 


Performance (continued) 



CDPI 

Power Switching Commands (No.)i 

0 


Time Tagged Commands (No,): 

0 


Other Commands (No.): 

0 


High Rate Telemetry 

Number of Analog Points (No.): 

0 


Number of Digital Points (No.): 

0 


Sample Rate (sec“^): 

0 


Word Length (bits): 

0 


Low Rate Telemetry 

Number of Analog Points (No.): 

2 


Number of Digital Points (No,): 

0 

I 

Sample Rate (sec"^) 

1 


Word Length (bits); 

8 

Safety 


Failure Model (flag): 

5 


Failure Parameters , q 

Failure Rate or Mean (x 10. hr): 

1700 


Standard Deviation (x 10"^*^ hr): 

N, A. 


Dormancy Factor (N.,D. ):*■'' 

0, 1 


Total Number of Redundant Elements (No.): 

12 

Cost 


Design Engineering ($1000): 

127 


Test and Evaluation ($ 1000): 

150 


Unit Production ($ 1000): 

9 


Reference Quantity (No.): 

4 


Factor (N. D. ) : 

1 

Schedule 


Development Lead Time Constant (months): 

3. 0 


Development Lead Time Variable (months): 

1.0 


Qualification Lead Time Constant (months): 

1.5 


Qualification Lead Time Variable (months): 

0. 1 


State-of-Art Factor (N. D.): 

1.0 

1 ^'Noii- dimensional 



5-9 





RELIABILITY MODEL 


5 . 3 

As a result of satisfying the input performance requirements, 
a finite number of designs are established by the Cost/Performance Model. 
The next step in processing these designs requires the use of the reliability 
equations. These equations are categorized as to reliability assessment, 
failure detection probability, and false alarm probability. 

The first of these equations, the reliability assessment, is used 
to calculate the reliability of each configuration. This is done at the ele- 
ment level, i. e., each identifiable subsystem component. Failure rate 
information stored in the equipment data base for each component is ex- 
tracted as needed by the model. The failure rates are then combined by 
the reliability equations to calculate total reliability for a given mission 
duration. The calculated reliability of each particular design is evaluated 
against the specified level provided as the model input. However, the 
design is not discarded if it does not me. ' the specified reliability level; in- 
stead, a search for the least reliable element is initiated. The criterion 
for least reliable is that element which, if made redundant, results in the 
largest increase in reliability or in mean mission duration per unit weight 
or cost increase. Upon identification, the least reliable element is paral- 
leled by an identical unit and the system reliability is recaleulated. The 
evaluation and paralleling process continue until the redundancy exceeds a 
specified limit. If the system still does not meet the specified reliability, 
the system is deleted from consideration as a viable single-string system. 
However, if it does meet or surpass the required reliability level, the 
system failure detection and false alarm probabilities are also calculated. 
The process described above continues until each design stored as a result 
of meeting performance requirements has been processed. 

The procedure described above constitutes one-half of the total 
reliability model. Following completion of the basic scheme, the whole 
procedure is repeated with each design mechanized as an active/ standby 
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(dual string) system. The term active/ standby refers here to a c ipletely 
separate system in addition to modular levels of redundancy. 

The required input data includes: 

a. Mission life 

b. System reliability 

c. Basis for selecting redundancy 

The output information supplied by the reliability model includes the 
redundancy required for each component and the amount of expendables 
(propellant) required. 

5.4 COST MODEL 

The cost model consists of cost equations which process cost 
information associated with each subsystem component. The required 
input data includes the number of qualification vehicles and flight vehicles. 

The cost model adds up the cost information for the following 
categories for every piece of equipment (up to 39 types) selected from 
the data base: 

a. Design engineering 

b. Test and evaluation 

c. Production engineering 

d. Unit production 

Cost estimating relationships (CERs) are used to estimate the 
costs for components which are not amenable to cataloging, including: 

a. Structure 

b. Thermal control 

c. Wiring 

d. Power conditioning equipment 

e. Solar arrays 

f. Propellant tankage 

The nonrecurring cost for each component takes into account 
design, development, the effects of redundancy, and yearly price changes. 
The average recurring cost for each equipment component is adjusted to 
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account for labor, materials, and yearly price changes. If mors than one 
unit is to be built, a learning curve is used to account for reduced unit 
cost as additional quantities are built. Remaining system cost categories 
including; 

a. Tooling and test equipment 

b. Quality control 

c. System engineering and integration, and 

d. Program management 

are estimated on the basis of predetermined percentages of the total of 
each of the four basic component cost categories. 

The total nonrecurring cost is the sum of the nonrecurring costs 
for all of the system components. The total recurring cost is the sum of 
the products of the equipment quantities and the appropriate average re- 
curring costs. The total spacecraft cost is obtained by summing the total 
recurring and nonrecurring costs and then adding in the mission equipment 
cost and contractor's profit. 

5. 5 SCHEDULE MODEL 

Schedule equations are used to estimate the amount of time re- 

quired to develop an operational system. In general, the estimates of the 
schedule lead times are functions of the hardware selected by the Cost/ 
Performance Model. The justification for such an approach lies in the 
fact that specific equipment components provide an indication of the com- 
plexity of the system and, hence, a measure of the time required to com- 
plete the activities associated with the system. 

The model performs the following operations: 

a. Computes the development and qualification lead times for 
each component. 

b. Computes the development and qualification lead times for 
each subsystem. 

c. Computes the system lead time. 

d. Determines the critical path. 

e. Computes the total program duration. 

The schedule model output includes the various lead times, the total pro- 
gram duration, and the critical path. 
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COMPUTER PROGRAM 


5. 6 

The Systems Cost/ Performance ivtodel has been implemented 
as a digital computer program. The program is written in the language of 
Fortran IV, as adapted to The Aerospace Corporation's CDC 7600 computer 
and MSFC's Unlvac 1108 computer. The program includes the Cost/Per- 
formance Model and the related data base. 

The Systems Cost/Performance Computer Program incor- 
porates three techniques to make the program as efficient as possible while 
retaining maximum versatility. The first technique is to pre-sort the 
equipment data base according to attributes specified by the program user,. 
This technique is desirable in order to allow the program to select equip- 
ment from the data base on the basis of the first piece identified which 
satisfies the requirements. 

The second technique consists of having the program always 
do a "macro" search of combinations of major subsystem configurations. 

As an example, one combination of major subsystem configurations would 
be a three-axis stabilized payload using cold gas propellant, oriented 
solar array paddles, shunt power regulation, and so forth. The subsystem 
configurations have been specified in Paragraph 5, 2. 1. 

The third technique is to mechanize the digital program to 
have the capability to try all combinations (micro- s earch) of equipment in 
any single subsystem, if requested by the user. The use^ must specify the 
configuration types for each of the other subsystems to exercise this option. 
The program will select, design, and print out all acceptable combinations 
of equipment for the specified subsystem. This technique or option allows 
the subsystem specialist to perform detailed trade studies. 

The general sequence followed by the computer program 
is to read the input requirements, make one pass through the subsystem 
design algorithms, determine the required redundancy, and then make a 
second pass through the subsystem design algorithms with the data obtained 
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from the first pass. Redundancy is not altered on the second pass 
primarily because the reliability model is extremely time-consuming. 

Cost and schedule are estimated for each acceptable design. 

5. 7 SIGNIFICANT RESULTS 

The major accomplishment of the effort was the develop- 
ment of a model possessing the ability to design unmanned, automated 
payloads. Subsystem, safety, cost, and schedule models were developed. 
Each of these models interfaces properly with the remainder of the 
model. The model is self-sufficient in that no intermediate steps need 
to be performed by the user. The Systems Cost /Performance Model 
has been implemented as a digital computer program and is operational 
on The Aerospace Corporation's CDC 7600 and IBM 370-155 computers 
and on MSFC's Univac 1108 computer. 

Three test cases were used to check the Cost/Perform- 
ance Model and the operation of the computer program. The three test 
cases were: 

a. Defense Satellite Communication System (DSCS-II) 

b. Earth Resources Technology Satellite (ERTS-A) 

c. Orbiting Solar Observatory (OSO-I) 

The test results were reviewed at the system, subsystem, and assembly 
levels. Table 5-2 compares the actual subsystem weights for DSCS-II 
with weights for the design generate i by the Model. 

The results of these three test cases indicate that the cur- 
rent Model is capable of estimating spacecraft program costs 'jvith reason- 
able accuracy. The error in the total cost estimate (using preliminary 
CERs) is less than 24% relative to the actual DSCS-II costs. Table 5-3 
compares the cost estimates for DSCS-II generated by the Model with 
the equivalent cost estimates generated by subsystem CERs. For these 
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Table 5-Z. DSCS-II Weight Estimate Comparison 


Weight (kg) 


Subsystem 

£stima>ted 
by Model 

Actual 

Weight 

Difference 

(%) 

Structures 

137. 3 

129. 7 

+ 1.3 

Thermal Control 

6.7 

17. 6 

-1.9 

Commuiilcation, Data Processing and 
Ins tr umentation 

22. 8 

58. 7 

-6. 3 

Electrical Power (Incl. Distribution) 

127.4 

14 7. 8 

-3.6 

Stabilization and Control 

67.2 

55.2 

+2. 1 

Auxiliary Propulsion 

39. 4 

13. 7 

+4. 5 

Expendables 

55.0 

55, 2 

0. 0 

Mission Equipment 

82. 1 

82. 1 

- 

Total Payload 

537. 9 

560. 0 

-3. 9 

Adapter 

6. 4 

6. 7 

-0. 1 

Launch W eight 

544.3 

566. 7 

-4.0 


Table 5-3. DSCS-II Cost Estimate Comparison 



Model Estimates 
($1000) 

Subsystem CERs 
($1000) 

DDT&E 

(63, 990) 

(61, 610) 

Spacecraft 

31, 690 

29, 310 

Mission Equipment 

32, 300 

32, 300 

Investment 

(61, 737) 

(49. 610) 

Spacecraft 

41, 697 

29, 570 

Mission Equipment 

20, 040 

20, 040 

Operations 

{ 2 , 157 ) 

(4, 540) 

Contractor Fee 

( 5,054) 

(4, 439) 

Total 

(132, 938) 

(120, 199) 


=i*The subsystem level cost estimates were generated by the current payload 
cost estimating model, PALCM. 
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program checkout casesi the model results are consistent with con- 
ventional cost- versus -weight CERs. 

Figure 5-3 presents the weight estimates generated by 
the model as a function of the payload reliability. The input requirements 
correspond to the DSCS-II payload, and the nominal design weight is 
identified by a small circle. The minimum weight, single string system 
has a weight of 440. 4 kg (970. 8 lb) and a mean mission duration (MMD) 
of 21.8 months. As the MMD requirement approaches 48 months, certain 
equipment (e. g. , the despin mechanical assembly and the mission 
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Figure 5-3. DSCS-II Weight versus Extended Life 
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equipment were not allowed to be made redundant) prevent the payload 
MMD from being increased further. The net result of the analysis 
is an interesting ai d logical understanding of the impact of the mean 
mission duration requirement on the DSCS-II launch weight. 

Generally speaking, the Cost/Pe rformance Model should 
exceed the performance of "top-down" models . The model uses a "bottom- 
up" approach and, therefore, designs the payload at the assembly level. 
Greater accuracy is achieved by the very nature of the more detailed 
design. This accuracy will be reflected in the cost and schedule model 
estimates. A second attribute of the Cost/Performance Model is the 
completeness of the design specified. Pieces of equipment are not 
forgotten, and redundancy is automatically included in the specified 
design. In addition, the impact of ail subsystem interfaces and inter- 
actions is properly modeled. The net result is a payload design which is 
as accurate and complete as one from a Pre- Phase A study and which is 
available to the Cost /Performance Computer Program user immediately. 

Because of the detailed nature of the model, the uses of 
the System Cost/Performance Model exceed that for "top-down" models. 

The following uses of the model are suggested: 

a. Pre-Phase A Planning 

1. Structure realistic programs in terms of matching 
performance, budgets, and schedule. 

2. Perform mission model analyses. 

3. Assess the potential savings from use of standardized 
equipment. 

b. Preliminary Design 

1. Establish specific payload designs and the related 
costs and schedule to meet the program requirements. 

2. Develop standardized designs using a data base 
consisting of standardized equipment. 
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Identify low cost designs using a data base con- 
sisting of off- -ne- shelf equipment. 

4. Perform modularity studies by modifying the 

model to assign equipment to modules. 

c. Program Management 

1. Assess contractor cost and schedule estimates. 

2. Determine the sensitivity of design, costs, and 
schedules to changes in requirements. 

3. Perform trade studies to identify optimal designs. 

4. Use in "Design to Cost " management. 

The model can readily be expanded in its scope to perform many other 
studies as well. Themodel will become a more versatile tool in terms 
of preliminary program planning and in actual program management as 
it becomes more fully developed. 
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6. STUDY LIMITATIONS 


The modeling activity was limited to unmanned, auto- 
mated payloads. There was no attempt to incorporate the effect or influ- 
ence of the Shuttle system on the design of payloads. 

Funding limitations prevented application of the Systems Cost/ 
Performance methodology to mission equipment and to ground support 
equipment and operations. The schedule model was deempha sized for the 
same reason. 

The focus of the current study was on developing a model 
rather than on augmenting a data base. Only after the model was success- 
fully developed and proven as a useful tool could data collection be justi- 
fied at such a detailed level. Most importantly, the current model is 
limited in the range of payload designs it can generate by the limited num- 
ber of equipment in the data base^ Accuracy of the cost estimates is limi- 
Led by the relatively limited amount of cost data which could be reduced 
and processed to support the data base cost entries. 



7. SUGGESTED RESEARCH AND ADDITIONAL EFFORT 


It is recommended that the model be thoroughly verified 
and validated. The most useful validation procedure would be to use the 
model on test cases selected from historical programs, operational 
programs, and new starts. Historical and current programs provide the 
most accurate data with which to validate the model. New start programs 
will test the applicability of the model as a preliminary planning tool. It 
is further recommended that the capability of the model to predict space 
vehicle interrelationships be tested and that the potential of the model 
to assist in programmatic change control such as configuration manage- 
ment be evaluated bv a user revitiw* 

Although the model is operational, there are a number of 
improvements which should be implemented. The suggested improvements 
in the subsystem, reliability, cost, and schedule models are listed below: 

a. Subsystem Models 


1. 

Stabilization and Control 


(a) 

Incorporate a magnetic torquer in the model. 

2. 

Data Processing 


(a) 

Incos'porate data compression in general 
purpose processors. 


(b) 

Incorporate selection of tape recorders in 
the model. 


(c) 

Incorporate an algorithm for selecting command 
distribution units. 

3. 

Communications 


(a) 

Expand the model from the Air Force's Space 


Ground Link System (SGLS) to include NASA's 
Unified S-Band (USB), S-Band and VHF 
equipment. 
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(b) Expand the model to apply to interplanetary 
missions. 

Structures 

(a) Incorporate a truss structural configuration. 

b. Reliability Model 

1. Incorporate mission equipment in the model with pro- 
vision for increasing redundancy of the mission equip- 
ment. 

2. Incorporate a model of pulse-operation (short duration) 
modules. 

c. Cost Model 

1. Improve the accuracy and applicability nf the data base 
and GERb by collecting and processing additional data. 

2. Develop CERs for equipmt=int not previously flown. 

3. Model the relationship between cost and schedule. 

d. Schedule Model 

1. Improve the approach and accuracy of the model by 
collecting and processing additional schedule data. 

In order to make the above improvements, it should be 
clear that additional cost, schedule, and technical data must be collected 
and processed. The focus of the current study was on developing a model 
rather than augmenting a data base. Only after the model was successfully 
developed and proven as a useful tool could data collection be justified at 
such a detailed level. On the other hand, lack of adequate data hindered 
the development of the current model. The cost model must be considered 
preliminary, and the schedule model cannot be considered operational 
until sufficient data have been collected to improve and validate the model. 
Hence, widespread use of the Systems Cost/ Performance Model depends 
entirely on the collection of performance, safety, cost, and schedule 
data at the subsystem component (assembly) level. 
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